
     Inter-Process Communication

First, remember what a process is. A "process" is a
running instance of a program (where a "program" is an
executable file stored in your file system). We make a
distinction between a "program" and a "process" because
a program, like Notepad, can have several instances of
itself running at any given time. Each such instance is
a different process (but each instance can be said to be
the same program). Notice that a process is to a program
much like an object is to a class.

In Operating Systems you learn that each process runs in its
own virtual memory space. Virtual memory spaces were invented
so that each process is purposely walled off from every other
process. You do not want a bug in one process (say an instance
of Word) to cause the crash of another process (say an instance
of Firefox). You also do not want one process (say an instance
of Firefox) to be able to look at, and read, the memory of
another process (say Word) and report back over the Internet
what you are typing in your Word documents. So for stability
and security reasons, process are strictly isolated from each
other (each in its own virtual memory space).

But if processes are strictly isolated from each other, they
cannot communicate, or cooperate, with each other. That is
too severe a restriction (think of how useful copy and paste
is, among many other ways in which programs communicate with
each other). So operating systems provide very tightly
controlled mechanisms for processes to communicate (and
therefore cooperate) with each other. These mechanisms are
referred to as Inter-Process Communication.

"Inter-Process Communication" (IPC) is when one process passes a
piece of data (a message) to another process. ALL forms of IPC
involve the operating system kernel to act as an intermediary
in the passing of the message (this is to try and guarantee the
stability and security of the whole system). In fact, every form
of IPC involves the kernel copying a segment of data (a buffer)
from the virtual memory space of the sending process into the
virtual memory space of the receiving process.


In this course we will learn about five mechanisms for IPC
(there are many more IPC mechanisms). They are,

1. files
2. command line arguments
3. environment variables
4. pipes
5. sockets

Files can be used by any two processes to communicate with each other
(more specifically, any two processes that have access to a shared
file system). In this sense, files are a very general form of IPC
(the messages can be as large as any file, the messages can be passed
in both directions, and the communicating processes need not even be
running on the same computer), but it is a very slow form of IPC.

Command line arguments can only be used by a parent process to pass
(in a one-way direction) a message to a child process (a child process
is a process that is started by the parent process). Also, this message
must be fairly small and it can only be sent at the time the child
process is created. So command line arguments are a fairly restrictive
form of IPC (but they get used a lot).

Environment variables are similar to command line arguments. They are
fairly small messages, they can only be passed in one direction (from
parent to descendant processes) and the messages must be sent at the
time the child process is created. The most significant difference
between environment variables and command line arguments is that an
environment variable is also inherited by every descendant of the
original child process. So an environment variable can be used to send
a message to every descendant of the parent process. There are times
when this feature can be very useful.

Pipes are a way for two sibling processes to communicate. Two processes
are siblings if they were created by the same parent processes. A pipe
must be created by the parent process and it must be created at the time
the two child processes are created. But otherwise, pipes are a very general
form of communication. We say that pipes are a form of "stream" communication,
in the sense that once the pipe is created, the two processes can pass an
unlimited stream of bytes through the (one-directional) pipe. The most common
way for a parent process to create a pipe between two child processes is for
the parent to have the operating system redirect the standard output of one
child process (the child that can send messages) to the standard input of the
other child process (the child that will receive messages). Pipes are very fast
(almost as fast as writing and reading from physical memory). The biggest
restriction on pipes is that the two processes must be running on the same computer.

Sockets are a way of providing stream communication between any two processes
running on the same or different computers (but connected together by a network).
Sockets are straightforward to use, they are very versatile, fairly fast,
and they are now ubiquitous (these days, every language running on every
operating system provides sockets). Sockets are the main subject of this course.


NOTE: If you want to see the parent/child relationship of all the processes running
      on your computer, run either the ProcessExplorer.exe or ProcessHacker.exe
      programs that are in the folder with this file (for ProcessExplorer.exe, be
      sure to select the menu item "View -> Show Process Tree").